Repositories
SVN Repository: https://svn.digipen.edu/projects/nasg42/ Mercurial Repository: https://hg.digipen.edu/projects/nasg42/ Download: http://tortoisehg.bitbucket.org/download/index.html How to Use TortoiseHG I'm going assume most people have TortoiseSVN and know how to use it so I won't go over that, but I know a lot of people haven't used TortoiseHG before. The first step will be to clone the repository. You should be able to right click anywhere in a folder or on your desktop and go to TortoiseHG -> Clone. After you click clone a window should pop up. In the "Source" text box put in the repository URL https://hg.digipen.edu/projects/nasg42/ . In the destination box, that is the folder that the repository will reside in, so change the name of the folder if you feel like it. That will download the most up to date files comitted to the server on the default branch. Now you will want to right click on the folder, and then select "Hg Workbench". It will open up this window where you will do a lot of managing for the repository. On the left side you will see the graph which is a visual representation of all the branches on the repository. A node that is a different color belongs to a seperate branch. On the branch section you can see what branch each revision belongs to. The branch named "default" is where the most stable content should be (though something will probably go wrong at some point). Over on the description column you can see a description of the commit, and some them also have tags on them that show up in green. Those are the heads of the branches. If you ever have two heads to a branch, you need to merge those together (more on this later). On the far right, you can see the "Phase" column. In there will be either public or private. Public means that it is successfully pushed out to the server and anyone can access it, while draft means it is only on your machine. On top if you click on the green check mark, that is where you will commit files to the repository. The blue text is files that have been modified and by default will have a checkmark next to them, and the pink text is any new file that is not in the repository yet and will not have a checkmark by default. Anything with a checkmark will be committed when you commit. On the right side you will see a box where you type in a message for the commit (and it forces you to type in something, try to at least explain what changes are being made if you can remember). Also hidden is where you can set what branch you want to commit to where it says "'Branch: default'". That'll bring you to another window where you can type in the branch name. ' For whatever reason something will pop up with an error message when you commit if you create a new branch so just make sure to click yes on the message that will pop up.' Finally you have the button that says "Commit" which will commit the changes to your own local repository. '''This does not mean that this is on the server yet, it is only on your machine.' Now we will dicuss how to actually pull from the repository and push to it as well. At the top of the window you can see a series of cylinders. The far left one will pull from the repository and will first ask you if you want to accept the changes (which is kind of worthless). The next one will pull from the repository but will just automatically accept the changes. The third one in line will push to the repository (but will ask you which revisions you want to push which again is pretty useless) and the last one will push to the repository. A very important thing to note is that even when you pull, you don't automatically get those changes. Looking at the following image, you can see the new revision branches off even though it is part of the same branch. In this case, you will want to update to that revision '''only if you haven't made any changes yourself' (it will give you an angry message saying you have some files modified that you are updating).''' To update to a revision, right click on it and select "Update". This will then update all the files in that revision so that you can use them. In the case you want to go to another branch, you do the same process, you right click on the revision and click update. Now this still has the same issue as before if you have any files that have been modified it will complain, especially since most branches will be considered "going backwards" through the branches so it will undo some files. There will be a case that you commit files and there is a revision you have to merge with. You are going to want to right click on the revision you want to merge with (the one with the circle around the graph is the revision you are currently on) and then click "merge with local". It will then try its best to merge the files that are conflicting (and sometimes it really sucks at it too). Don't worry if things get messed up though, you can always revert files. You will probably run into this a few times where you push and a scary error message will come up. You need to follow the thing it says and first pull and then merge with those changes in order to continue. The Plan for the Repositories So the plan from this point foward is to use the Mercurial repository for storing more and moving a lot of what used to be on the SVN repository to Mercurial, like sound assets and the build of the game. This will require multiple branches from each sub team (programming, sound, and design) where default will be the combination of the different branches which will (hopefully) be stable and working. I (Alex T) will be making sure things are merge together correctly and keeping each main branch updated (where a main branch will be a branch for each discipline) along with default. This does not mean I will be merging people's personal branches with their group's branch (example being a programmer with their own branch wanting to merge into the programming branch). There shouldn't be any cross merging either like design merging with programming where the proper thing to do would be to go through the default branch. Now there will be exceptions as these things come up and that will probably be on a case by case basis. Let's just try to keep from breaking everything. As for SVN, we will still be using it but for somewhat useless files like fbx files that still need to be archived for various reasons.